PsL Monthly 1993 December/PSL Monthly Shareware CD-ROM (December 1993).iso/prgmming/dos/pascal/dataval.exe/DATAVALD.TXT

Text File | 1991-09-10 | 26KB | 465 lines

Data Validation Techniques
In Turbo Vision


by Danny Thorpe

presented at the
Borland Languages Conference
April 1991


Data Validation Techniques in Turbo Vision
Turbo Vision, the new object-oriented event-driven application
framework introduced in Borland's Turbo Pascal 6.0, has generated quite
a bit of excitement in programming circles.  With Turbo Vision,
programmers finally have the tools and application framework necessary
to create programs that can truly benefit from the OOP methodology.
Programmers benefit from the variety of objects in Turbo Vision that can
be molded and extended into a multitude of application-specific dialog
boxes, windows, and other views.
Turbo Vision is a multi-faceted environment.  At a superficial
level, it is a library of interrelated objects for managing the screen
display.  At another level, though, Turbo Vision is also an application
framework which defines a particular model of how a program should work,
both internally and visually.  It is this model and its framework
embodiment that provides the glue which ties the objects in the library
together into a functional society of objects.  A large portion of the
increased programmer productivity that can be realized with Turbo Vision
is due to this model as well:  the application framework you inherit
takes care of the actual mechanics of the program, so the programmer has
just to plug in modules and create cross-connections between objects.
While many programmers appear to accept the code changes necessary
to move to Turbo Vision, some are reluctant to also embrace the
programming model that is an important part of Turbo Vision.  Without
this model, one can wind  up using Turbo  Vision objects in ways that
work against the grain of the programming model, creating unnecessary
complexity and frustration for the programmer.
A large portion of any program involves feeding in data for the
program to operate on.  Traditional techniques for interactive data
entry are particularly difficult for programmers to give up when
learning Turbo Vision.  This paper will discuss some of the philosophy
behind Turbo Vision, the mechanics of various internal operations in
Turbo Vision, and why some of the old data entry techniques won't work
anymore.  Alternate approaches to data entry and validation more in line
with Turbo Vision model will be introduced and demonstrated.


The Turbo Vision Model
The Turbo Vision user interface is based upon the IBM System
Application Architecture, Common User Access specification.  CUA
provides guidelines that determined the behavior of the mouse, input
lines, push-buttons, and the choice of keys for particular actions, such
as Esc to cancel a dialog and Enter to select the default button of the
dialog.
A driving force in the Turbo Vision programming model is the idea
that the user of the program should be in control of the program at all
times.  Let the user do what he wants to do, within reason.  This
doesn't sound very remarkable at first, but when you consider how few
programs on the market allow the user this freedom, you begin to realize
that an unnecessary evil has been lurking in computer software: too many
restrictions are imposed upon the user by the program/programmer, to the
point that the software is in control of the user.
Of course, a program needs structure in order to organize its
information into a meaningful form.  The user needs the information to
be structured, too, in order to understand the material.  The difficulty
comes in finding the fine line between the amount of structure needed by
the user and the amount of structure that begins to stifle the user with
unnecessary conditions and requirements.  Programs frequently wind up on
the stifling end of the scale simply because they're easier to write and
manage.  With traditional programming tools it is difficult to construct
a well-balanced, flexible program that considers all contingencies the
user may wish to embark upon.
With Turbo Vision, you inherit a well-balanced, flexible program
architecture and then fill in the details of what your application is to
do.  At the lowest levels in the object hierarchy, Turbo Vision views
have the ability to be manipulated by the user in a multitude of ways.
But the programmer doesn't have to bend over backwards in Turbo Vision
to accomplish this user freedom.  All the programmer has to do is work
within the Turbo Vision model to extend the behavior of view objects
that already know how to interact with the user.
The Turbo Vision model provides an environment based on autonomy
and independence.  The careful integration of OOP and event driven
programming provides the programmer with a rich set of tools and opens
doors to programming solutions nearly unattainable by traditional
methods.  Working in this model actually provides the programmer more
flexibility in expression and more opportunity to bring sophisticated
applications to completion than traditional programming tools can offer.



Traditional Validation Techniques
As-You-Type Validation
One method of ensuring an input field contains "clean" data is to
monitor each keystroke the user types.  Keys can be checked by position
within the input field if the validation is controlled by a template.
Formatting telephone number fields with a template like [phone],
where '9' means 'accept any number in this position' is a common use of
as-you-type validation.  If a non-numeric key is pressed, the key
monitor can beep or provide some other non-intrusive indicator of an
error.  The other characters in the template can be treated just as
place-holders, so the user doesn't have to enter the parentheses for
every phone number, for example.
As-you-type validation is good for position-sensitive formatting
of data, such as telephone numbers or dates, and for character
conversions, such as converting all characters entered in a field to
uppercase as they are typed.  As-you-type is difficult to use when
numbers or whole words need to be validated before being accepted,
because you don't really know what the user intends until the user is
finished typing, backspacing, and correcting misspellings.
Templates are easy to implement in Turbo Vision:  make a
descendent of a TInputLine object and extend the HandleEvent method to
test each keystroke received by that view.  Acceptable keystrokes can be
passed to the inherited HandleEvent for default processing, and
unacceptable keys can be discarded with a beep and/or non-intrusive
error message.
As-You-Leave Validation
Another opportunity to test the data is when the user moves the
cursor out of the field, presumably to the next field on the screen.
This method assumes that when the user hits the Tab key or Enter key to
move to the next field, the user is finished keying this field, and so
it is fair game for validation.  Validation is performed before the
program moves focus to the next field.
If the contents of the field are unacceptable, it is common for an
error message to be displayed, and the user is put back in the bad field
to reenter it.  This is where a poorly designed data entry system can be
really mean to the user - what if the user decides to cancel the whole
data entry operation?  It would be the job of every field to watch for a
particular "cancel" key, such as F1 or Esc, and shut down the data entry
mode when such a keystroke occurs.
Data can be tested as the user leaves a field in Turbo Vision.
However, the traditional response of forcing the user back to a field
after the user has indicated he wants to go elsewhere conflicts with the
Turbo Vision model.  Consequently, this behavior is difficult to
implement in Turbo Vision, mainly because it requires different
assumptions about the user and environment than Turbo Vision assumes.  A
detailed explanation of the focus change mechanism is covered in the
next section.
As-you-leave validation assumes that when the user leaves the